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(54) Resource reservation in 3G or future generation telecommunication network III 



(57) In the UMTS, resource reservation is provided 
by translating Resource reservation Protocol context 
messages into and out of Packet Data Protocol messag- 
es, the processing being carried out by the translation 
interface (31) of a mobile terminal (30) which has asso- 



ciated terminal equipment (32); the terminal equipment 
can then be GPRS/UMTS unaware. The RSVP messag- 
es are mapped between the mobile terminal (30) and 
the Gateway support node (26) and regenerated as ap- 
propriate. 
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Description 

[0001] This invention relates to telecommunications 
networks operating the Internet Protocol (IP), and re- 
lates especially to a method of reserving resources. 
[0002] In third generation (3G) telecommunications 
networks, such as Universal Mobile Telecommunication 
System (UMTS), broad bandwidth is provided for serv- 
ices such as data and multimedia in addition to voice. 
An obvious need is that required Quality of Service 
(QoS) should be provided to users, but in IP networks, 
if contention for resources is not resolved, then QoS 
cannot be guaranteed. 

[0003] In IP networks or the Internet in general, Re- 
source reservation Protocol (RSVP) is used to allow the 
network to reserve resources so as to provide QoS. 
RSVP can be used for QoS control locally or it may be 
used across IP networks. 

[0004] RSVP is an end-to-end protocol and is illustrat- 
ed in Figure 1 . A transmitting user 1 0 sends to a receiv- 
ing user 12 a message PATH. The PATH message car- 
ries the traffic characteristics information such as 
Tspecs to indicate the traffic behavior that is to be sent 
from the user 1 0. When the receiving user receives the 
PATH message, it sends a RESV message which con- 
tains QoS requests such as FlowSpecs. In practice, the 
transmitting and receiving users 10, 12 can be located 
remotely so that PATH and RESV messages pass 
through several nodes in UMTS. As each node receives 
either of the messages, it makes a decision as to wheth- 
er adequate resources in that node can be reserved. If 
this is possible, then the messages are relayed to the 
next hop for the PATH message and to the previous hop 
for the RESV message. When the RESV message 
reaches the transmitting user 10, it begins to transmit 
data. 

[0005] Periodic refresh messages are sent subse- 
quently to maintain the QoS status at each node in which 
it has been set up. 

[0006] RSVP messages need to pass from the Mobile 
Terminal (MT) to the Radio Access Network (RAN) and 
then to the Core Network formed by the CN Edge and 
the Gateway GPRS Support Node of the GPRS/UMTS. 
Passage of additional RSVP messages means that ex- 
tra radio resources must be allocated to guarantee that 
the RSVP messages can pass through the air interface 
reliably and instantly. Lost or delayed RSVP messages 
mean longer or failed call set-up, and even dropped 
calls, and loss of QoS guarantee during handover. 
[0007] At the TSG-SA Working Group 2 Meeting no. 
12 in Tokyo, 6-9 March 2000, a disclosure was made by 
applicant of an arrangement in which a mobile system 
using RSVP was able to communicate with a non-RSVP 
application in associated terminal equipment (TE); 
RSVP messages to and from the TE are intercepted by 
the mobile terminal and translated into and out of sec- 
ondary PDP Context messages by the mobile. The mo- 
bile analyses the RSVP parameters carried in the PATH 
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message, and determines whether to create a new sec- 
ondary PDP context or to modify an existing context. In 
both cases an updated QoS status is provided. The sec- 
ondary PDP context is then created/modified using ex- 
5 isting PDP context control procedures. 

[0008] On successful establishment of a secondary 
PDP Context, the mobile activates an RSVP proxy to 
terminate RSVP messages. The RSVP proxy is respon- 
sible to receiving and processing the PATH messages 
10 and generating the RESV messages in response. 
[0009] However, it is necessary to provide a proxy in 
the mobile terminal, which adds to cost and complexity. 
[001 0] It is an object of the invention to. provide an im- 
proved arrangement which does not add to cost or corn- 
's plexity of the mobile terminal. 

[0011] According to the invention, in a third or future 
generation telecommunication network, a method of al- 
locating resources for user traffic passing between a 
mobile terminal and a remote user, there being terminal 
20 equipment associated with the mobile terminal, charac- 
terized in that Resource reservation Protocol messag- 
es are processed only within the mobile terminal. 
[0012] In the accompanying drawings, Figure 1 illus- 
trates the operation of RSVP. The invention will be de- 
25 scribedby wayof exampleonly, with reference to figures 
2 and 3 in which:- 

Figure 2 illustrates schematically the UMTS QoS ar- 
chitecture for the control plane; and 
30 Figure 3 illustrates the interchange of messages in 
a downlink. 

[0013] In Figure 2 the UMTS 20 comprises a Core 
Network (CN) 22 formed by a Gateway GPRS Support 
35 Node 24 and a CN Edge 26; there is also a UMTS Ter- 
restrial Radio Access Network (UTRAN) 28. A MT 30 
communicates with the UTRAN 28 across a radio inter- 
face. The MT 30 is connected to Terminal Equipment 
(TE) 32 which runs non-UMTS specific applications. 
*o The MT30 is UMTS specific, and is capable of process- 
ing the traffic from the TE 32 to channel it appropriately 
to the UMTS, usually to the radio access network. 
[001 4] The Gateway 24 communicates with an Exter- 
nal Network 40. 
45 [001 5] The U MTS 20 operates the application-specif- 
ic Packet Data Protocol (PDP) context as usual to ne- 
gotiate the QoS and activate the QoS control between 
the MT30 and UMTS network 20. 
[0016] Figure 3 shows the message exchanges in a 
so downlink. For traffic QoS control in the downlink, the 
RSVP processing entity in the MT 30 needs to be trig- 
gered. On receipt of a PATH message from the TE 32, 
the MT 30 forwards the message; the MT 30 decides 
whether to modify an existing PDP Context message or 
55 to create a new secondary PDP context message. 
[0017] The secondary PDP Context message is 
passed through the UTRAN 28 to the CN Edge 26, 
which passes a create/modify PDP Context Request 



EP 1 154 599 A1 



40 



45 



50 



2 



EP1 154 599 A1 



message to the Gateway 24, which filters out the PATH 
message and passes it to the External Network 40. On 
receipt of a RESV message in return, the process is re- 
versed. 

[0018] The MT 30 extracts the TrafficSpecs (eg 
Tspecs of IntServ) in a PATH message and applies it to 
the traffic characterization. For a RESV message, the 
MT extracts the QoS specs, eg FlowSpecs of IntServ, 
and applies the QoS requirements. The process is also 
carried out by the receiving TE in the External Network 
40. 

[001 9] The MT 30 extracts the Traffic Specs, such as 
Tspecs of IntServ, in a PATH message and applies it to 
the traffic characterization. For a RESV message, the 
MT extracts the QoS Specs, such as FlowSpecs of 
IntServ, and applies the requirements. 
[0020] It is now proposed that in the MT 30, the exist- 
ing translation interface 31 (see Fig. 2) filters the RSVP 
message and interprets the QoS requirements that are 
carried in the RSVP messages and converts them into 
the QoS profile of GPRS/UMTS PDP context. 
[0021] When an RSVP message is generated by the 
generic RSVP interface attheTE32 and is then passed 
to the translation interface 31 in the MT 30, the transla- 
tion interface 31 converts the QoS objects into the PDP 
context QoS profile which complies with the QoS defi- 
nitions of GPRS/UMTS. 
[0022] A simple mapping relationship is: 

RSVP Guaranteed Service (GS) = > GPRS/UMTS 

Conversational Service Class 

RSVP Controlled Load Service (CL) = > GPRS/ 

UMTS 

Streaming Service Class and Interactive Service 
Class 

Best-effort Service (BE) = > GPRS/UMTS 
Background Service Class 



when appropriate. 

[0026] The advantages of the functions performed at 
the MT30 are that 

5 a) The MT can be upgraded quickly to cater for new 
features in the QoS control API (Application Pro- 
gramming I interface) 

b) Allows access independent API at the application 
level 

10 c) Allows interface specific controls to override non- 
interface specific settings for non-mobile aware ap- 
plications 

d) Allows tight customer control of expensive radio 
resources 

15 e) Allows appropriate control of the radio access re- 
gardless of whether it is an IP service or a PPP 
(Point to Point Protocol) service being provided 
f) The MT under the control of the end application 
can determine by using RSVP whether to modify an 

20 existing PDP context or create a new PDP context 
to provide the QoS needs of each RSVP session. 

The MT30 and SGSN 24 or GGSN 26 are also required 
to check if RSVP messages are a) sent/received for the 

25 first time so as to initiate PDP Context set-up if appro- 
priate; b) modified, in order to initiate PDP Context Mod- 
ification procedure if appropriate; or c) merely refresh 
messages to trigger local generation of response. 
[0027] The MT 30 and the GGAN 24 also need to 

30 check if RSVP messages are a) sent/received for the 
first time, so as to initiate PDP context set up; b) modi- 
fied, so as to initiate PDP context modification proce- 
dure; ore) merely refresh messages to trigger local gen- 
eration of responses. 

35 [0028] A further advantage of use of the inventive 
method is that theTerminal Equipment 32 can be GPRS/ 
UMTS unaware and can therefore be generic 



[0023] The above mapping relationship between 
RSVP services and the GPRS/UMTS services are 
maintained in the Gateway 24 and the MT with further 
extension on the PDP context to accommodate the 
mapping content. After the PDP context is set up, the 
Gateway 24 regenerates the RSVP message that orig- 
inates from the MT (or the TE) and relays it to the in- 
tended remote end (the receiving application) in the Ex- 
ternal Network 40. 

[0024] Upon receiving the RESV message sent from 
the remote end as a reply to the MT-originated PATH 
message, the Gateway 24 terminates a message and 
notifies the receipt of an RSVP message from the re- 
mote peer end to the MT. The translation interface will 
then re-map the GPRS/UMTS QoS classes into RSVP 
QoS objects and regenerates an RSVP message as a 
reply from the remote peer end application to the RSVP 
originating application at the TE. 
[0025] Thus the RSVP messages are not transmitted 
through the UTRAN but are mapped and recreated 



40 Claims 

1. In a third or future generation telecommunication 
network, a method of allocating resources for user 
traffic passing between a mobile terminal (30) and 
45 a remote user, there being terminal equipment (32) 
associated with the mobile terminal, characterized 
in that Resource reservation Protocol messages 
are processed only within the mobile terminal. 

so 2. A method according to Claim 1 in which said mes- 
sages are processed by a translation interface (31) 
within the mobile terminal (30) 

3. A method according to Claim 2 in which the trans- 
55 lation interface (31) is arranged to translate Re- 
source reservation Protocol messages into and out 
of Packet Data Protocol Context messages. 
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A method according to Claim 2 or Claim 3 in which 
the translation interface (31) is arranged to map the 
Resource reservation Protocol messages. 

A method according to any preceding Claim in 
which Resource reservation Protocol messages 
are also mapped by the Gateway support node(26). 
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